Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/x400ops/x400ops-minutes-91mar.txt

Text File | 1993-02-17 | 14KB | 380 lines

CURRENT_MEETING_REPORT_


Reported by Kevin Jordan/CDC

X400OPS Minutes

Review of Agenda

The Agenda was approved without change.  Although, some minor
adjustments were made as the meeting progressed.

Review of Charter

It was made clear that the focus of the Working Group is the operation
of X.400 mail on the Internet.

Rob Hagens presented a one page draft document describing the strategy
for deployment of X.400 in the Internet.  The goals described in the
document were reviewed and discussed.  The goals drafted by Rob were:


   o The X.400 service will not, in the near future, completely replace
     existing Internet mail service.

      -  It was pointed out that this is an assumption, not a goal.  It
         was suggested that a useful goal would be to work with the SMTP
         Verison 2 Working Group in order to facilitate gatewaying
         between SMTP V2 and X.400.

      -  People who had attended the SMTP V2 meetings on Monday, 3/11,
         reported briefly on what was discussed there.  It seems that
         the SMTP V2 Working Group has just begun defining requirements,
         so judging from previous experience, it will probably be at
         least two years before SMTP V2 is widely implemented and
         operational.


   o The X.400 service in the Internet shall be fully connected to the
     existing Internet Mail service via gateways.


      -  It was recommended that this goal be revised so that it
         includes a clause about the need for X.400 gateways to be
         highly interoperable with the existing Internet mail services.



                                   1






   o The X.400 service in the Internet will be connected to
     international  R&D  X.400 service initiatives.


      -  UW-Madison has already established a direct X.400 link to
         Norway, Finland, Canada, UK, France, Switzerland and Spain.
         The Norwegian connection has agreed (at least for now) to act
         as a relay between XNREN and the other participants of the
         COSINE X.400 project in Europe, not directly connected to
         XNREN.


   o The X.400 service in the Internet will be connected to major ADMD
     providers in the U.S., provided that a suitable arrangement can be
     made.


      -  There was general consensus that this is a very important goal.
         However, it is not yet clear how this goal will be attained due
         to the fact that the ADMD providers are commercial
         organizations who normally account and charge money for their
         services.

      -  On the second day of meetings, Vint Cerf indicated that CNRI is
         already pursuing this goal.  CNRI is willing to provide the
         physical plant necessary to provide a connection to an ADMD
         provider, but human resource limitations may delay
         implementation.  Rob Hagens indicated that UW-Madison could
         help.


   o Although the 1984 protocols may be used on an experimental basis,
     the primary deployment of X.400 should be based upon the 1988
     version of X.400.


      -  It was recommended that this goal should be rewritten in terms
         of driving toward general deployment of 1988 X.400 (or perhaps
         1992 X.400), but that it is also necessary to provide backward
         interworking with 1984 X.400.  Conversion from 1984 to 1988 to
         1992 and beyond will not occur all at once.  The transitions
         will probably be gradual, so backward interworking is
         desirable.


   o With respect to management domains, the Internet will be organized
     as a collection of Private Management Domains.


Finally, the Technology section of the draft document contained the
following statement:

                                   2






     The X.400 service in the Internet will conform to the US GOSIP
     profiles.

It was recommended that this statement be qualified because, for
example, GOSIP requires OSI lower layers, but the Interent X.400 service
will be based primarily upon TCP/IP (RFC1006) initially.

Relationship to other techinical groups

Some members of the X.400 Operations Working Group are also members of
other technical groups.  It was suggested that this informal cross
participation would be used for communications between the X.400
Operations group and other groups.  The groups mentioned were:  IETF-DS,
IETF-ODA, RARE-WG1,  R&D  MHS Managers, NIST Workshops.

Round table presentation of current X.400 service status

Each of the Working Group participants discussed how X.400 is being used
(or is planned to be used) within his/her organization.  Most sites are
planning to use X.400, but are not using it actively yet.  Notable
exceptions are UW-Madison and CDC; these organizations are actively
using X.400 now.

Overall organization of the X.400 service in the Internet


   o Technical requirements
     Two types of MTA's were defined:


      -  MTA's supporting RFC1006, informally called Internet MTA's
      -  MTA's supporting TP0/X.25, informally called PDN MTA's


     It was generally agreed that organizations wishing to particpate in
     the Internet X.400 project should support Internet MTA's, meaning
     that participating organizations should provide an MTA which
     supports RFC1006.
     However, the Working Group does not want to preclude participation
     by organizations which are connected only to X.25-based PDN's.
     Such an organization will need to make a bilateral agreement with
     an organization which supports both RFC1006 and TP0/X.25, and
     arrange for that organization to relay mail between the X.25-based
     connection and the RFC1006-based Internet connection, or each PRMD
     should implement mechanisms to insure end-user connectivity on top
     of both stacks.
     We should also be prepared to serve MTA's connected to the TP4/CLNP
     infrastructure.

                                   3






     It was noted that these technical requirements are essentially the
     inverse of the connection requirements established by COSINE for
     its members.  COSINE requires all participating organizations to
     support TP0/X.25 connections to their respective country's PDN.
     RFC1006 is not defined as mandatory by COSINE. This implies that
     interconnection of COSINE and the Internet X.400 project will:


      -  require a relay in the U.S. to support both X.25 and RFC1006,
         or
      -  require a relay in Europe to support both X.25 and RFC1006.
         This, in fact, is the current state of affairs, or
      -  combinations of a.  and b.  above.


     It was generally agreed that GOSIP should serve as a reference
     document for X.400 upper layer technical requirements, where
     ``upper layers'' is defined to be the OSI Session layer and the
     layers above it.
     The term ``Internet WEP'' was introduced to identify a special MTA
     acting as a Well-Known-Entry-Point for an Internet PRMD. UW-Madison
     will distribute a draft definition of an Internet WEP to the list
     for review.

   o Internal organization of PRMD's
     It was agreed that naming authority should be hierarchically
     organized.  Specifically, the names of organizations should be
     coordinated with the PRMD's in which the organizations are created.
     Similarly, the names of organizational units should be coordinated
     with the organizations in which the organizational units are
     created (but not necessarily with the PRMD administrators).
     UW-Madison will maintain a list of Internet PRMD's.
     UW-Madison will maintain FTP-able documents which describe
     participating organizations and information about MTA's (e.g.  MTA
     connection information).  ONLY operational organizations and MTA's
     will be described in these documents.
     It was agreed that an important characteristic to describe about an
     MTA is its ability to operate over both RFC1006 and TP0/X.25.
     Publishing this characteristic will make it easy for prospective
     participants supporting only TP0/X.25 to locate existing
     participants who might be willing to act as Internet relays.
     UW-Madison will distribute a draft definition of an MTA document
     format to the list for review.


Specification of RFC822 addresses in the X.400 world

It was agreed that RFC822 addresses should be expressed using X.400
domain defined attributes.  Furthermore, a special PRMD named
``Internet'' will be defined to facilitate the specification of RFC822
addresses.  For example, an X.400 user will address an RFC822 recipient


                                   4






by constructing an X.400 address such as:


     /c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/


Participating MTA's will be configured to recognize ``/c=us/admd=
/prmd=Internet/'' as a special case.  The presence of this address will
cause a message to be routed to a regional RFC987 gateway.  In effect,
this special PRMD identifies a community of gateways to RFC822
recipients.  This strategy is user friendly in that all users everywhere
need only remember this one gateway address, and it is efficient in that
it avoids having to establish a single, common gateway which would tend
to become a bottleneck and single point of failure.

Specification of X.400 addresses in the RFC822 world

After considerable discussion, it was agreed that RFC822 users should be
able to address X.400 recipients in RFC822/Internet terms.  This implies
the necessity of maintaining and distributing address mapping tables to
all participating RFC987 gateways, at least in the short term.  Other
mapping strategies were discussed (loudly and enthusiastically), but it
was shown that these alternate strategies would sometimes cause messages
(or replies to messages) to pass through more than one gateway.  Since
this behavior would probably cause information to be lost in
translation, it was quickly agreed that the alternate strategies were
inferior to the good old table driven approach.

Nevertheless, it was also pointed out that some X.400 addresses do not
map cleanly to RFC822 addresses, even when the table driven mapping
strategy is used.  For example, X.400 personal names which contain
generation qualifiers, personal names which contain initials but no
given name, and initials which contain periods can not be mapped to
RFC822 symmetrically such that a reverse mapping is possible.
Similarly, X.400 addresses which contain X.121 address elements
(sometimes used for expressing fax telephone numbers), unique UA
identifiers, or physical addressing attributes can not be mapped nicely.
Consequently, it will be necessary for RFC987 gateways to generate
RFC987 address syntax occasionally.

It was recommended that our RFC should contain guidelines for the
creation of X.400 personal names.  In following these guidelines, users
will avoid creating personal names which can not be mapped nicely
between X.400 and RFC822.

It was generally agreed that long term reliance upon static mapping
tables is unacceptable.  Therefore, it was agreed that the X.400
Operations Working Group should devise a strategy for using X.500
directory services instead.

                                   5






Another option could be to use the DNS system for this purpose, if the
X.500 infrastructure appears to be too premature.

Future issues

The following list of issues were agreed to be important for the future
service, and the group should follow these issues closely:


   o X.400/84 <--> 88 interworking.
   o Use of DNS for RFC 987 address mapping management
   o Use of an X.500 infrastructure for routing, table management and
     user catalog purposes.
   o Body types other than text.


Presentation of outline for RFC

Rob Hagens proposed an outline for the RFC to be produced by the Working
Group.  Participants made comments and suggested additions.

UW-Madison will write a first draft and distribute it to the list for
review.

Future meetings

A tentative meeting has been scheduled for May 30 and 31.  This meeting
will be held in Madison, Wisconsin or San Jose, California.  The purpose
of the meeting will be to resolve comments against the draft RFC, in
case there are comments which can not be resolved via email.

The next general IETF meeting is scheduled for July 29 - August 2 in
Atlanta, Georgia.  The X.400 Operations Working Group will definitely
meet at that time.

Action items



Rob Hagens   Update and distribute the X.400 Internet Service Strategy
             document.
             Update and distribute outline for the RFC.

Alf Hansen   Write and distribute a definition of ``Internet WEP''.

                                   6






Kevin Jordan  Distribute minutes from St.  Louis meeting.  Distribute
             the X.500 schemas used by CDC to record information about
             X.400 routes, MTA's, and address mappings.  Include a
             description of how these schemas are used by CDC's X.400
             products.
             Distribute a description of CDC's extensions to RFC987 in
             support of multipart/multimedia X.400 messages.



Attendees

Vikas Aggarwal           [e-mail]
Vinton Cerf              [e-mail]
Cyrus Chow               [e-mail]
Alan Clegg               [e-mail]
John Dudeck              [e-mail]
Ned Freed                [e-mail]
Charles Fumuso           [e-mail]
Shari Galitzer           [e-mail]
Tony Genovese
Robert Hagens            [e-mail]
Alf Hansen               [e-mail]
Kevin Jordan             [e-mail]
Mukesh Kacker            [e-mail]
Jim Knowles              [e-mail]
Ruth Lang                [e-mail]
Mike Little              [e-mail]
John Reinart             [e-mail]
Ursula Sinkewicz         [e-mail]
Michael Stanton          "[e-mail]"
Michael Tharenos         [e-mail]
Linda Winkler            [e-mail]
Russ Wright              [e-mail]



                                   7